Most people now have a collection of small plastic cards, representing various credit cards, store cards, identity cards, membership cards, and so on. Information about the card and its owner, such as account details and so on, is normally printed or embossed on the card, and may also be stored in some form of magnetic strip. Note that such cards are simply passive storage devices, and the information that they contain is fixed at card creation time.
In recent years, smart cards have also proliferated. These are similar in scale to traditional credit cards, but incorporate within their plastic cases a microelectronic memory and also (optionally) an embedded processor. It will be appreciated that the computational resources available within a smart card are extremely limited compared to those of a desktop workstation, or even a laptop or handheld device. One especially popular form of smart card is known as a Java Card. This is based on the Java platform developed by Sun Microsystems (“Java” and “Java Card” are trademarks of Sun Microsystems Inc). In such devices, a Java virtual machine (VM) is provided within the smart card to allow the execution of Java applets or applications. Particular advantages of being able to use the Java environment for smart card applications are the inherent security features of the Java environment, plus the ready availability of software development packages for the Java programming language. It is estimated that by the end of 2002 over 200 million Java cards had been shipped. More information about the Java Card smart card platform is available from the page: /products/javacard/ at the web site: http://java.sun.com and from the site: http://www.javacardforum.org/.
An Application Programming Interface (API) is defined for the Java Card platform. Applications written in the Java programming language invoke this API to access the Java Card run-time environment (JRE) and any native services. The Java Card API allows application portability, in that the same application can run on any smart card that supports the API. The Java Card API is compatible with international standards, in particular the ISO/IEC 7816 family of standards.
Note that programs that run on smart cards may be referred to as either an application or as an applet. It will be appreciated that there is a clear distinction between a Java applet and a Java application in a desktop environment, in particular the absence of a main class from the former. However, this distinction does not apply in the smart card environment. Thus applets for use on a Java card platform are not the same as applets that run on a web browser. The term applet will generally be used herein to refer specifically to code, and the term application to refer to the higher level functionality provided by the applet code and associated data (unless the context requires otherwise).
The Java Card platform supports multiple applications on a single card. These may be separated by firewalls, in order to ensure that they do not interfere with one another. This is particularly of concern if the various applications are operated by different organizations, whose business relationships with the cardholder may be independent of one another.
FIG. 1 is a high-level schematic diagram illustrating the main architectural components in a typical smart card application. In particular, smart card 102 belonging to cardholder 101 interacts with a terminal 110 by exchanging an application protocol data unit (ADPU) 108. The format for the ADPU is defined by the International Standard ISO/IEC 7816-3.
Terminal 110 may be a handheld device, an adjunct to a desktop workstation, a dedicated card reader (analogous to an ATM) or any other suitable system. Furthermore, the communications between the smart card 102 and the terminal 110 may be by wired connection, such as some form of bus (e.g. USB), or by wireless link (e.g. radio or some other electromagnetic signal), depending on the particular devices concerned. In addition, the terminal 110 may be under the direct control of an operator 111 (such as for a handheld terminal), or alternatively terminal 110 may be automated (such as for an ATM).
Terminal 110 interacts with a back office 130 over any suitable form of network 120, such as the Internet, a local area network (LAN), a wide area network (WAN), and so on. Back office 130 may comprise multiple systems (not explicitly shown in FIG. 1), such as a web server or portal attached to network 120, perhaps with an application server and/or a database system behind. Note that the terminal 110 may be off-line until activated by a smart card 102, a card holder 101 or a terminal operator 111 to access a back office 130 over network 120.
In operation, the cardholder 101 typically places the card 102 into or adjacent to the terminal 110, thereby allowing the two to interact, e.g. to perform a debit operation from the card, in order to purchase some goods. This interaction will generally be referred to herein as a session, and typically involves the exchange of multiple messages between the smart card 102 and the terminal 110. A session can be regarded as comprising multiple transactions, where each transaction represents the completion of some portion of the overall session (e.g. a security authorization).
Associated with each applet on smart card 102 is an Application Identifier (AID). The AID is a byte string up to 16 bytes long, whose format is defined by International Standard ISO/IEC 7816-5. Thus according to this standard; the first 5 bytes of the AID represent the registered application provider identifier (RID) and have a value allocated by ISO or one of its member bodies. The RID generally indicates the merchant or other entity involved with operating the applet, hereinafter referred to as the RID operator. The RID operator is generally responsible for the back office program 130, and is depicted as application/RID operator 131 in FIG. 1. The last 11 bytes of the RID constitute the proprietary application identifier extension (PIX). The PIX is determined by the RID operator 131, and can be used to store a reference number or other information associated with the applet.
FIG. 1A illustrates the storage of the AID on a typical smart card 102. The AID bytes are stored in a byte array, which represents internal storage for a Java AID object 161. Applications can therefore access the AID by making appropriate calls to AID object 161, which in effect provides a wrapper for the underlying byte array.
International standard ISO/IEC 7816-4 defines a procedure to allow a terminal to locate a desired application on a smart card, and this is illustrated at a high level in the flowchart of FIG. 1B. The procedure starts when the smart card 102 is first inserted into the terminal 110. The terminal detects the insertion of the smart card (reference numeral 162), and in response to such detection activates the smart card (reference numerals 164, 172). This activation typically includes providing power to the smart card.
The terminal now sends a request using an application protocol data unit (ADPU) 108 to the smart card (reference numeral 166). The ADPU identifies the application to be used in this session in terms of its AID. The request from the terminal is received by the smart card (reference numeral 174), typically within an applet selector program that is running on the smart card 102 as part of a card executive layer. The applet selector is then responsible for locating and launching the application that matches the AID request from the terminal, i.e. the application that has the same AID as specified in the request (reference numerals 176 and 177). The smart card also returns the AID for the matching application back to the terminal 110 (reference numerals 179 and 180). (N.B. Reference numerals 179 and 180 are optional within the context of ISO/IEC 7816-4, although commonly implemented).
FIG. 1C describes a variation on the above approach (also in accordance with ISO/IEC 7816-4), in which the terminal 110 supplies the card with a truncated AID (known as a partial AID), for example the first ten bytes of an AID. In these circumstances, there may be multiple matches against the partial AID. For example, if two applets have AIDs that have the first ten bytes in common, and then differ only in the final six bytes of the AID, they will both match the same partial AID of length 10 bytes (or less). One reason for using a partial AID might be if the terminal 110 wants to identify all applets on the card having a particular RID.
The processing of FIG. 1C commences as just described for FIG. 1B, except that at reference numeral 166 the request from the terminal 110 to the smart card 102 comprises only a partial AID. Consequently, the smart card may identify multiple matching applications at reference numeral 176. The AIDs for these matching applications are then returned to the terminal 110 (reference numerals 179, 180), in order to allow the terminal (or user) to select a specific desired application from those matching the partial AID. Thus the terminal now sends a request to the smart card to launch an applet (reference numeral 182). This request specifies the particular applet to be launched on the smart card in terms of its complete AID (generally selected from the set of those received from the smart card at reference numeral 180). The smart card duly responds to this request by launching the applet selected by the terminal (reference numeral 190).
In fact, the skilled person will realize that although FIG. 1C represents an appropriate logical model for the use of partial AIDs, the actual implementation looks more like FIG. 1B (primarily for historical reasons). Thus current systems generally accommodate the matching and return of multiple matching AIDs by identifying only a single matching AID at a time. In particular, the applet having the AID that is first matched to the partial AID received from the terminal is launched, and the complete AID for this applet is returned to the terminal 110. The smart card then only supplies a next matching AID upon a subsequent specific request from the terminal. Nevertheless, it will be appreciated that multiple matching AIDs could be handled in other ways, such as by returning the complete set of multiple matching AIDs all at once in a single response to the terminal (as depicted in FIG. 1C).
FIG. 2 is a schematic diagram representing the life cycle of a smart card, which in this particular implementation is a Java Card. This life cycle commences with the manufacture of the card, and the initial loading of the base operating system and the Java Card environment (reference numeral 210). Also at this stage, one or more applications may be preloaded (reference numeral 215). Generally, the base operating system and Java Card environment, and also potentially any preloaded applications, may be stored in ROM on the smart card 102 as part of the manufacturing process.
The card is now ready for issue to a cardholder (reference numeral 220), which typically involves an appropriate personalization process, as well as initialization of the Java environment, and starting the Java virtual machine on the card. The cardholder is thereafter able to use the card (reference numeral 230), such as in the manner illustrated schematically in FIG. 1. Note that if the card was originally issued without any preloaded applications, then the cardholder may have to load an application prior to making substantive use of the card. In practice however, this situation is rather uncommon, since usually there is at least one preloaded application in order to motivate issuance of the card in the first place.
During the operational lifetime of the card, further application programs may potentially be installed onto the card (reference numeral 235), for example if the cardholder signs up to new accounts or services. Conversely, applications may be removed from the card, perhaps because an account is closed.
The last operation shown in FIG. 2 is where the card is terminated (reference numeral 240). This may occur, for example, because the card has a built-in expiry date or is surrendered by the user (perhaps if the user is moving to a new card issuer, or the card is physically damaged).
Although the Java Card environment does support multiple applications from different RID operators, nevertheless, in practice, the installed applications on a large majority of issued cards come from and are run by a single RID operator. In other words, applications from one RID operator are typically found on one card, and applications from another RID operator on a different card. Consequently, relatively little attention has been paid to the business and technical problems associated with the provision and utilization of multi-vendor smart cards.